Skip to content

8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file updates #25429

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 7 commits into
base: pr/25425
Choose a base branch
from

Conversation

AlanBateman
Copy link
Contributor

@AlanBateman AlanBateman commented May 24, 2025

Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file to include thread state and lock information. Also update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a description of the JSON format dump as that format is intended to be parseable/read by tools.

This PR is dependent on pull/25425. As noted in that PR, the changes accumulated in the loom repo, and have been split up to make it easier to review.

The changes include some re-implementation of ThreadDumper. This is because it used PrintStream and didn't fail if there was an I/O error, e.g. file system full. Furthermore, the indentation to pretty print the json was fragile and hard to maintain so this is changed to use a supporting writer class to do this.

Test coverage is significantly expanded, including updating the test library that is used by several tests to parse the thread dump.

Testing: tier1-6


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change requires CSR request JDK-8356872 to be approved

Integration blocker

 ⚠️ Dependency #25425 must be integrated first

Issues

  • JDK-8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file updates (Enhancement - P3)
  • JDK-8356872: HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file updates (CSR)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/25429/head:pull/25429
$ git checkout pull/25429

Update a local copy of the PR:
$ git checkout pull/25429
$ git pull https://git.openjdk.org/jdk.git pull/25429/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 25429

View PR using the GUI difftool:
$ git pr show -t 25429

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/25429.diff

Using Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented May 24, 2025

👋 Welcome back alanb! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

openjdk bot commented May 24, 2025

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

@openjdk openjdk bot added the csr Pull request needs approved CSR before integration label May 24, 2025
@openjdk
Copy link

openjdk bot commented May 24, 2025

@AlanBateman The following labels will be automatically applied to this pull request:

  • core-libs
  • hotspot
  • jmx
  • serviceability

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

@AlanBateman
Copy link
Contributor Author

/label remove hotspot
/label remove core-libs
/label remove jmx

@openjdk
Copy link

openjdk bot commented May 24, 2025

@AlanBateman
The hotspot label was successfully removed.

@openjdk
Copy link

openjdk bot commented May 24, 2025

@AlanBateman
The core-libs label was successfully removed.

@openjdk
Copy link

openjdk bot commented May 24, 2025

@AlanBateman
The jmx label was successfully removed.

@AlanBateman AlanBateman marked this pull request as ready for review May 24, 2025 07:36
@openjdk openjdk bot added the rfr Pull request is ready for review label May 24, 2025
@mlbridge
Copy link

mlbridge bot commented May 24, 2025

Webrevs

* text or JSON format.
* This class defines static methods to support the Thread.dump_to_file diagnostic command
* and the HotSpotDiagnosticMXBean.dumpThreads API. It defines methods to generate a
* thread dump to a file or byte array in plain text or JSON format.
*/
public class ThreadDumper {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
public class ThreadDumper {
public final class ThreadDumper {

sb.append(String.format("\\u%04x", c));
} else {
sb.append(c);
private static class JsonWriter {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
private static class JsonWriter {
private static final class JsonWriter {
private static final class Node {

@AlanBateman AlanBateman changed the base branch from master to pr/25425 May 25, 2025 06:16
@openjdk openjdk bot removed the csr Pull request needs approved CSR before integration label May 28, 2025
@AlanBateman
Copy link
Contributor Author

Sync'ed up to the pull/25425.

for (StackTraceElement ste : thread.getStackTrace()) {
ps.print(" ");
ps.println(ste);
private static void dumpThread(Thread thread, TextWriter writer) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the non-json text format for locks: here we're creating a new comment-like style:
// parked on ..etc...

In the regular Thread.print we always used a "-" prefix, and always printed the frame, then the relevant locks, like:

    at ThreadsMem$2.run(ThreadsMem.java:38)
    - waiting to lock <0x0000000630817da0> (a java.lang.Object)

    at java.lang.ref.ReferenceQueue.remove(java.base@25-internal/ReferenceQueue.java:215)
    - locked <0x0000000630802350> (a java.lang.ref.ReferenceQueue$Lock)

Could we use the same? We have a lot of history reading the established style. 8-)
Can we match the old-style "waiting to lock" rather than "waiting on" ?

I realise I'm asking to move the printing of "waiting to lock" into the loop over the stackframes, and it affects various tests.

Copy link
Contributor Author

@AlanBateman AlanBateman May 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When parked and there is a parkBlocker, blocked entering a monitor, or waiting in Object.wait, then it gets printed between the summary/state (first line) and the stack trace. I think this is a bit clearer that printing it after the top frame but okay to change. Note that the output isn't going to look the same as the traditional thread dump as it prints the object's identity hashcode rather than the address.

For the "locked" output then you may have a point, been back and forth on this. For synchronized methods then I think it's clearer when it is printed between the caller and synchronized callee. For synchronized blocks then it's clearer when to see which method has entered the monitor. Picking one means it's not clear in all cases but maybe people are just so used to "- locked" and don't notice. Can look at this again, it's trivial to swap between the two.

jsonWriter.writeProperty("time", now);
if (thread.isVirtual()) {
jsonWriter.writeProperty("virtual", Boolean.TRUE);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Q: Is the order of dumped properties important?
The JSON schema lists the virtual property after the state:

 51                         "tid": {
 52                           "type": "string",
 53                           "description": "The thread identifier."
 54                         },
 55                         "time": {
 56                           "type": "string",
 57                           "description": "The time in ISO 8601 format that the thread was sampled."
 58                         },
 59                         "name": {
 60                           "type": "string",
 61                           "description": "The thread name."
 62                         },
 63                         "state": {
 64                           "type": "string",
 65                           "description": "The thread state (Thread::getState)."
 66                         },
 67                         "virtual" : {
 68                           "type": "boolean",
 69                           "description": "true for a virtual thread."
 70                         },

The other properties dumped in the dumpThread() follow the order defined in JSON schema.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Q: Is the order of dumped properties important?

No, the ordering doesn't matter. The intent with the schema in the API docs is that we have somewhere to describe the objects name properties. If you re-order then it still validate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rfr Pull request is ready for review serviceability [email protected]
Development

Successfully merging this pull request may close these issues.

6 participants